Beyond the discussion above we should move these files over. This is just an administrative task rather than any substantial change to the spec. @tedsuo and @bogdandrutu can you please approve.

I think this proposal is missing an important element: declaring which parts of the attribute namespace are "reserved" for typed span data, which are for user attributes, etc. (e.g. can we declare that regardless of the type of the span, that most application data should be, for instance, prefixed with app.[appname].?

I believe this PR is a little bit ambiguous as it is. IMHO, it should be split into multiple standalone-pieces:

1. Propose canonical type (with some concrete type-names)
2. Semantic conventions per canonical type (these already exist, but maybe could use some refinements, better documenation, connection to concrete canonical types)
3. Actual typed span APIs to help create spans that with proper attributes, that match semantic conventions for specific types.
4. Fix "component" field inconsistency, because it partially overlaps with the "canonical type"
   • For HTTP, the definition is component:http, whereas for Database component:<name-of-db)
   • could also be part of 1.

Closing this PR after some discussion.

• We probably won't need a canonical type (we will check presence of attributes and apply a fixed resolution for multiple type spans, e.g. DB wins over HTTP).
• Semantic conventions are discussed separately in the Data Formats meeting.
• We should make a new OTEP/push for typed span APIs.